Add SAP Business Partner example for the ontology layer by marioapiphani · Pull Request #310 · apache/ossie

marioapiphani · 2026-08-09T10:13:27Z

examples/ has one ontology-layer example today (flights.yaml). This adds a second, drawn from an enterprise ERP domain, that exercises ontology constructs the existing example does not reach:

entity subtyping — Customer declares extends: [ BusinessPartner ]; flights.yaml has no EntityType subtyping
a derived population — Customer uses concept-level derived_by to define its population as exactly those business partners carrying a customer number, rather than asserting it. flights.yaml uses derived_by only on relationships, for derived attributes.
four-part compound identity — CustomerSalesArea is identified by customer + sales organization + distribution channel + division. The existing example tops out at two parts.

It also covers ground shared with flights.yaml — value types with requires, associations with and without functional multiplicity, verbalizations in both reading directions, and ontology_mappings down to a logical model — so it stands alone as a reading example.

Source-system provenance (SAP Data Dictionary domains and check tables) is recorded in the descriptions, showing one way to keep technical origin alongside a business-level model.

The README's examples/ entry is updated to name both ontology-layer models.

The file validates against ontology/ontology.json as shipped, with core-spec/osi-schema.json registered to resolve the remote $ref from the checkout:

import json, re, yaml
from jsonschema import Draft202012Validator
from referencing import Registry, Resource
onto = open("ontology/ontology.json").read()
core = Resource.from_contents(json.load(open("core-spec/osi-schema.json")))
reg = Registry().with_resources([(u, core) for u in set(re.findall(r'"\$ref": "(https://[^"#]+)', onto))])
v = Draft202012Validator(json.loads(onto), registry=reg)
print(sorted(v.iter_errors(yaml.safe_load(open("examples/sap_business_partner_ontology.yaml"))), key=lambda e: list(e.path)) or "VALID")

Prints VALID. No code changes.

🤖 Generated with Claude Code

An ontology-layer model of a Business Partner domain, exercising entity subtyping with a derived population, four-part compound identity, value types with requires constraints, associations with and without functional multiplicity, verbalizations, and ontology_mappings to a logical model. Validates against ontology/ontology.json as shipped.

jochenchrist · 2026-08-18T17:24:30Z

Could you provide the original data model?

jochenchrist · 2026-08-18T17:25:09Z

Also curious, if there are some properties missing in Ossie?

jbonofre · 2026-09-07T14:37:20Z

+      a closed-world assumption.
+    extends: [ BusinessPartner ]
+    derived_by:
+      - "EXISTS ( BusinessPartner.customer_nr )"


derived_by requires EXISTS ( BusinessPartner.customer_nr) , but customer_nr has no link_mapping anywhere in the BusinessPartner nor CUSTOMER_SALES_AREA has a field that could feed it.

Running this file's own mapping yields zero Customer objects, so the derived-population feature this example is meant to demonstrate can't actually be observed.

jbonofre · 2026-09-07T14:42:43Z

+    derived_by:
+      - "EXISTS ( BusinessPartner.customer_nr )"
+    relationships:
+      - name: has_sales_area


There's no concept: Customer entry anywhere in concept_mappings, only BusinessPartner and CustomerSalesArea are mapped.

has_sales_area gets zero link_mappings and zero derived_by, so this relationship (meant to illustrate "association without functional multiplicity") can never by populated.

jbonofre · 2026-09-07T14:47:40Z

+    relationships:
+      - name: customer
+        roles:
+          - concept: Customer


These look like the same real-world relationship modeled as two independent declarations instead of one dual-verbalized relationship, the pattern ontology.md's Person.parent_of uses.

That means keeping them in sync by hand, and as noted above, the Customer.has_sales_area side isn't even mapped.

jbonofre · 2026-09-07T14:50:35Z

+        multiplicity: ManyToOne
+        verbalizes:
+          - "{CustomerSalesArea} covers division {Division}"
+      - name: delivery_blocked


DELIVERY_BLOCK exists in the CUSTOMER_SALES_AREA dataset specifically for this, but CustomerSalesArea's concept_mapping stops after division, there's no delivery_blocked link_mapping. Compare flights.yaml's canceled flag, mapped via FLIGHT.id WHERE ( FLIGHT.cancelled == TRUE ), for the pattern this is missing.

jbonofre · 2026-09-07T14:56:25Z

+                - relationship: nr
+                  expression: "BUSINESS_PARTNER.BP_NUMBER"
+            children:
+              - relationship: BusinessPartner.category


These LinkMapping.relationship values are concept-qualified, but ontology.md's worked example and every occurence in flights.yaml use bare relationship names for LinkMapping.relationship (concept-qualification is for ReferentMapping.relationship instead).

If the mapping engine resolves by exact local name, category/full_name/country would never resolve and stay unpopulated.

jbonofre · 2026-09-07T15:02:29Z

+      population from a country dataset rather than enumerating values here.
+    extends: [ String ]
+    requires:
+      - "LENGTH(CountryCode) = 2"


This is the only bare = in the file/corpus, every sibling constraint uses <= and ontology.md/flights.yaml use == exclusivity for equality. Worth double-checking the ontology-layer expression dialect accepts bare =. Separately, SAP's LAND1 field is commonly CHAR(3), so an exact length-2 constraint would reject legitimate 3-character country codes.

jbonofre · 2026-09-07T15:13:03Z

+          - referent_mappings:
+              - relationship: customer
+                referent_mappings:
+                  - relationship: BusinessPartner.nr


Customer declares no identify_by of its own, and neither the spec nor the schema says whether identify_by is inherited via extends ("inherit" doesn't appear anywhere in ontology.md/spec.md/the JSON schemas).

Worth flagging that against the actual converter, identify_by is built only from a concept's own YAML list, so Customer.identify_by resolved {} here.

On top of that, lookup_concept_relationship always prefixes f"{concept.name}.{name}", so an already-qualified value like BusinessPartner.nr would get double-prefixed and fail to resolve. This isn't specific to this file (it'd hit ontology.md's own CustOrder.nr example too), but this PR looks like the first example to actually exercise this path.

jbonofre · 2026-09-07T15:15:36Z

+  - concept: CountryCode
+    type: ValueType
+    description: >
+      Country key. Technical origin: DDIC domain LAND1, check table T005.


This says population comes "from a country dataset" preserving the T005 check-table relationship, but no such dataset exists in ontology_mappings (the actual mapping just copies BUSINESS_PARTNER.COUNTRY straight through.

It might be worth correcting the description or adding the dataset it describes.

jbonofre · 2026-09-07T15:17:33Z

+
+  # ---- Value types carrying DDIC domain semantics -------------------------
+
+  - concept: BusinessPartnerNumber


The six sibling ValueType.requires blocks mix block-list and inline-flow YAML style for structurally identical constraints. Given this file is meant as a template for future SAP fields, a consistent style would help (and might have caught the = 2 issue 😄 ).

jbonofre self-requested a review August 9, 2026 13:26

jochenchrist added the ontology label Aug 18, 2026

jbonofre reviewed Sep 7, 2026

View reviewed changes

Navigation Menu

Uh oh!

Add SAP Business Partner example for the ontology layer - #310

Add SAP Business Partner example for the ontology layer#310
marioapiphani wants to merge 1 commit into
apache:mainfrom
marioapiphani:example-sap-bp-ontology

marioapiphani commented Aug 9, 2026

Uh oh!

jochenchrist commented Aug 18, 2026

Uh oh!

jochenchrist commented Aug 18, 2026

Uh oh!

jbonofre Sep 7, 2026

Uh oh!

jbonofre Sep 7, 2026

Uh oh!

jbonofre Sep 7, 2026

Uh oh!

jbonofre Sep 7, 2026

Uh oh!

jbonofre Sep 7, 2026

Uh oh!

jbonofre Sep 7, 2026

Uh oh!

jbonofre Sep 7, 2026

Uh oh!

jbonofre Sep 7, 2026

Uh oh!

jbonofre Sep 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants


		# ---- Value types carrying DDIC domain semantics -------------------------

		- concept: BusinessPartnerNumber

Uh oh!

Conversation

marioapiphani commented Aug 9, 2026

Uh oh!

jochenchrist commented Aug 18, 2026

Uh oh!

jochenchrist commented Aug 18, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants